The kargs-proc-cmdline-quoted test was parsing `ostree admin status`
text output with a sed regex that assumes the line ends with the
deployment serial. Status annotations like "(pending)" break this;
just reuse $host_commit from libinsttest.sh instead.
For soft-reboot, make the initramfs regeneration check non-fatal
since dracut can fail inside bwrap in CI VMs. The kargs-based
kernel state check still covers the same rejection path.
lzwind [Wed, 5 Aug 2026 01:13:34 +0000 (09:13 +0800)]
build: Remove G_GNUC_CONST from *_get_type declarations
GLib removed G_GNUC_CONST from its *_get_type declarations to avoid
miscompilations with GCC trunk, and recommends downstream projects do
the same. See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5223
lzwind [Wed, 5 Aug 2026 00:59:56 +0000 (08:59 +0800)]
find-remotes: Don't require write access to repo unless pulling
ostree find-remotes is a read-only operation that searches for remotes
which have a given collection-ref. It should not require write access
to the repository. Only when --pull is used does the command actually
write to the repo.
Move the ostree_ensure_repo_writable() check to just before the pull
phase so that read-only find-remotes works on read-only repositories.
Philip Withnall [Tue, 4 Aug 2026 15:56:43 +0000 (16:56 +0100)]
tests: Add simple tests for `ostree summary` key commands
Add simple tests for `--list-metadata-keys` and `--print-metadata-key`,
mostly just to check that they don’t include signature verification
output, but also as a smoketest.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Philip Withnall [Tue, 4 Aug 2026 15:52:53 +0000 (16:52 +0100)]
ot-builtin-summary: Verify signature when viewing a summary file
So now we can run `ostree summary --repo . --view --gpg-homedir
/path/to/servers/gpg-homedir` and it’ll verify the GPG signatures.
That’s not so useful for verification per-se, since if you’re running
this on a server you’d expect the signatures you’ve generated to verify
correctly. It’s more useful to see how many signatures are on the
`summary` and which subkeys were used to generate them, when messing
around with multiple signing keys.
Aside from this, there is no way (that I know of) to inspect the
signatures on a summary file without checking out a copy of the
repository and hoping that the client has got a full copy of the keyring
containing all relevant subkeys.
The verification output is very similar to that of `ostree show`.
Note that signatures are not verified if running with `--raw`,
`--list-metadata-keys` or `--print-metadata-key`, since clients may be
parsing the output of those commands.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Philip Withnall [Tue, 4 Aug 2026 15:49:43 +0000 (16:49 +0100)]
ostree-repo: Add a new ostree_repo_verify_local_summary() API
This will be used in the following commit to add signature verification
to `ostree summary` when used to view the summary of a local repository.
It needs to be separate from `ostree_repo_verify_summary()`, as that API
expects to take a remote name and use the keyring for that remote. As
far as I can tell there isn’t a way to use an arbitrary GPG homedir to
verify a summary file, as is needed when running on the OSTree server
rather than on a client checkout.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There were a couple of issues here, related to passing a `GError**` into
a sub-function inside a loop:
- If multiple calls inside the loop failed (e.g. if multiple keys
inside the file were invalid, because it was a malformed file), the
`GError` would be overwritten and cause a critical warning from GLib.
- If an early iteration failed, but then subsequent ones succeeded, the
`_load_pk_from_stream()` function would return `TRUE` but would also
set its `GError`, which is a very non-standard (basically prohibited)
thing to do with a `GError` argument.
Fix that by using a `first_error` variable internally and only
propagating it to the caller on failure.
This can be reproduced by trying to verify a signature using a key file
which isn’t actually a key file:
```
ostree sign --verify --repo ./my-repo $commit_id \
--keys-file ./test.published.gpg
```
The keys file is expected to be in a custom format, with one ed25519 key
per line. An ASCII-armoured GPG keyring is not that format, and causes
it to go big boom.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Philip Withnall [Mon, 3 Aug 2026 15:30:28 +0000 (16:30 +0100)]
ostree-blob-reader: Add error handling for invalid base64 blobs
One cannot base64 decode the empty string, so catch that case (which can
happen if asked to load a malformed key file) early before it causes an
assertion failure inside GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Colin Walters [Fri, 31 Jul 2026 18:18:38 +0000 (14:18 -0400)]
static-delta: Account for the full part payload consistently
The previous commit adding a limit here didn't account
correctly for metadata overhead; in trying to do it as a private
security fix we didn't run all of the tests, which was a procedural
mistake.
Assisted-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
prepare-root: Properly check return value of snprintf()
When the target buffer is to small to hold the resulting string a value
larger or equal than the buffer's size is returned. (In pre C99
versions, snprintf returned -1 in this case, too.)
So to ensure that no truncated paths are used adapt the error checking
accordingly.
static-delta: Validate decompressed size against declared usize
Each delta part header already declares the expected uncompressed
size of the resulting objects. Pass that through to
_ostree_static_delta_part_open() and use it as the decompression
limit when it is smaller than the hard cap. This catches a
crafted delta that declares a small usize (passing the free-space
pre-check) but actually decompresses to something much larger.
The hard cap (512 MiB) remains as a backstop when the declared
size is unavailable (e.g. the show/dump path passes 0).
static-delta: Reject oversized parts at generation time
Error in finish_part() when the uncompressed payload exceeds the
consumer-side limit, so that an oversized --max-chunk-size fails
at delta creation rather than producing content clients reject.
static-delta: Add resource limits for LZMA decompression
A malicious repository can serve crafted static delta content that
exhausts client memory and disk during ostree pull before checksum
validation completes.
Cap the LZMA decoder memory to 100 MiB (matching RPM's default) and
bound decompressed delta part output to 512 MiB. The size limit is
enforced on both compressed and uncompressed code paths.
Jonathan Lebon [Fri, 24 Jul 2026 17:02:58 +0000 (13:02 -0400)]
lib/commit: Fix min-free-space accounting for reflinked content objects
When writing a content object,
create_regular_tmpfile_linkable_with_content() opportunistically tries
FICLONE to reflink data from the input fd. The reflinked file shares its
data blocks via copy-on-write, so the actual disk cost is just metadata.
However, the min-free-space accounting in write_content_object()
reserves the full file size in max_blocks upfront and never credits it
back after a successful reflink. Over many files this causes max_blocks
to diverge significantly from actual free space.
Propagate the reflink status from
create_regular_tmpfile_linkable_with_content back to
write_content_object so it can credit back the reserved blocks,
following the same pattern used for duplicate objects in 16e537cb
("lib/commit: Fix min-free-space accounting for duplicate content
objects").
This should fix the CI issues in
https://github.com/coreos/fedora-coreos-config/pull/4265.
Heavily AI-guided investigation and resolution and red-green testing.
Jonathan Lebon [Thu, 23 Jul 2026 15:17:54 +0000 (11:17 -0400)]
tree: Go back to git.mk-generated .gitignore
Commit b0cd80d9 ("ci: Add Packit CI with RPM builds and TMT integration
tests") added an in-tree .gitignore which trips up the `git.mk` bits
which normally generate it. And so then build artifacts showed up all as
untracked files.
Go back to keeping `.gitignore` untracked and instead add `.cosa` to
`GITIGNOREFILES` to retain the original entries that b0cd80d9 added.
Jonathan Lebon [Thu, 23 Jul 2026 02:09:15 +0000 (22:09 -0400)]
lib/commit: Fix min-free-space accounting for duplicate content objects
First, in the _ostree_repo_bare_content_commit(), we never actually
checked whether the file was already present in the repo before linking
it in place. Do this so that we can no-op up front.
Second, and the actual bug this patch is fixing: the min-free-space
accounting in write_content_object() and
_ostree_repo_bare_content_commit() optimistically reserves space from
the running `txn.max_blocks` counter _before_ knowing whether we'll
actually no-op or not based on the object already existing.
Over many duplicate writes within a single transaction, the counter
diverges from the actual free space and eventually hits zero, causing a
spurious "min-free-space would be exceeded" error even with plenty of
disk space available.
This may be the source of the CI issue FCOS is hitting in
https://github.com/coreos/fedora-coreos-config/pull/4265 due to the
bootc SELinux relabeling done since
https://github.com/bootc-dev/bootc/pull/2088.
This patch saves the number of blocks reserved and credits them back in
both code paths when a duplicate object is detected.
This was heavily AI-guided, finding the bug, and then doing red-green
testing towards the fix.
Add an `out_existed` output parameter to
`_ostree_repo_commit_tmpf_final()` and `commit_loose_regfile_object()`.
This requires switching from `GLNX_LINK_TMPFILE_NOREPLACE_IGNORE_EXIST`
to `GLNX_LINK_TMPFILE_NOREPLACE` so we can detect `G_IO_ERROR_EXISTS`
ourselves.
No users for now. Prep for a follow-up patch using this.
tests/bsdiff: add content_size guard boundary test
Add test_bspatch_content_size_guard to verify the integer truncation
guard added for RHEL-189207. The test exercises the exact boundary
condition used in dispatch_bspatch():
It validates that:
- Values with bit 63 set and G_MAXUINT64 are always rejected
- On 32-bit systems, values above G_MAXUINT32 (4 GiB) are rejected
including the PoC value 0x100001000 (4 GiB + 4 KiB)
- Normal values (0, 1, 4096, 1 GiB) are accepted and the casts to
gsize and int64_t produce correct values
static-delta: guard bspatch against integer truncation on 32-bit
On 32-bit systems (sizeof(gsize)==4), the attacker-controlled
content_size (a guint64) is silently truncated when passed to
g_malloc0(), which takes gsize. Meanwhile bspatch() receives the
full 64-bit value as int64_t newsize and writes according to it,
producing a heap buffer overflow.
Add an explicit check that content_size fits in both gsize and int64_t
before the allocation. Use separate typed locals (alloc_size, newsize)
to make the truncation-free intent clear and pass newsize to bspatch().
electricface [Mon, 29 Jun 2026 08:03:23 +0000 (16:03 +0800)]
repo-commit: preserve existing object inode when staging to objects/
When ostree commit --consume is used and an object with the same
checksum already exists in objects/, rename_pending_loose_objects() was
unconditionally renaming the staging copy over it. On Linux, renameat(2)
atomically replaces the destination for two regular files, silently
changing the inode of the existing repo object.
Fix this by checking whether the object already exists in objects/
before renaming. If it does, the content is identical by definition
(the object store is content-addressed by SHA256), so we can simply
unlink the staging copy and keep the existing object with its original
inode.
Exception: .commitmeta objects are keyed by commit checksum rather than
their own content, so they can be updated in place (e.g. when GPG
signatures are added or deleted via ostree gpg-sign). These are always
renamed unconditionally.
The 3-way merge of bootconfig-extra during staging breaks bootc
loader-entries set-options-for-source when called multiple times on the
same boot. Each call sets the desired x-options-source-* keys on the
merge deployment's in-memory bootconfig, but the merge logic gives
higher priority to the previously staged data, overriding the caller's
updates. This corrupts the source-tracking metadata that bootc relies
on to compute override_kernel_argv, causing stale kargs to persist
across reboots.
The scenario this commit was trying to fix (rpm-ostree re-staging after
bootc on the same boot, preserving bootc's extension keys) will need a
different approach that does not conflict with callers that update
extension keys across multiple stagings.
prepare-root: create /run/systemd/volatile-root for composefs
systemd resolves the block device backing the root filesystem via
blockdev_get_root(), which checks "/" and falls back to "/usr". With
composefs enabled both are overlayfs mounts with an anonymous st_dev
(and prepare-root intentionally skips the read-only /usr bind mount in
that case), so the lookup finds no device. As a result
systemd-gpt-auto-generator silently skips all partition discovery: the
ESP is never automounted on /boot, which in turn breaks tools that
expect the bootfs to be reachable, e.g. bootctl, systemd-bless-boot
(boot counting) and "ostree admin status" when the loader entries live
on the ESP.
systemd provides a hook for exactly this situation: if the root mount
has been replaced by some form of volatile file system, the original
root block device is expected to be symlinked at
/run/systemd/volatile-root. Create that symlink when composefs is in
use. Note the target must be in the /dev/block/MAJ:MIN form since
systemd parses it without ever going to disk
(device_path_parse_major_minor()).
The root device is resolved as follows: prefer /dev/gpt-auto-root when
it exists, since on systemd-based initrds udev has already identified
the root partition for us (EFI boot with LoaderDevicePartUUID set and
a discoverable-partitions-spec root partition type). Otherwise fall
back to stat()ing the root mountpoint, which also covers initrds
without systemd (e.g. meta-updater). Since btrfs reports an anonymous
st_dev (major 0) for its mounts, in that case query the backing device
via BTRFS_IOC_FS_INFO/BTRFS_IOC_DEV_INFO the same way systemd's
btrfs_get_block_device_fd() does, refusing multi-device filesystems
just as systemd does. This matters in practice as Fedora Atomic
Desktops default to composefs on btrfs.
bootc solves the same problem the same way for its composefs-native
backend: bootc-root-setup.service (gated on the composefs= karg) runs a
gpt_workaround() that creates this exact symlink. That service is
ordered after ostree-prepare-root.service, so with this change the
symlink already exists by the time it runs; bootc is being updated to
tolerate that instead of failing. See also the systemd discussion of
gpt-auto with overlay roots:
https://github.com/systemd/systemd/issues/35017
Failure to create the symlink is not fatal: the system boots fine
without it, only auto-discovery of auxiliary partitions is degraded.
In bf59d0c6 we added `OSTREE_ADMIN_BUILTIN_FLAG_UNLOCKED` to the
instutil subcommands, including `set-kargs`. At the time, this flag
only controlled sysroot locking, and the commit message notes these
commands were "only used by Anaconda" so locking was unnecessary.
However, 599ffefe later consolidated mount namespace setup into the
same `if (!UNLOCKED)` block, so `UNLOCKED` now also means "skip
`ostree_sysroot_initialize_with_mount_namespace()`". Without the
mount namespace, `_ostree_sysroot_ensure_writable()` is a no-op, and
any subsequent write to `/sysroot` fails with EROFS on systems where
the sysroot is mounted read-only (the default since composefs).
Dropping the flag is safe for the installer case: when not booted
into an ostree-managed system, `initialize_with_mount_namespace()`
returns early (since `root_is_ostree_booted` is FALSE), and the lock
acquisition is harmless on a writable target sysroot.
ci: Remove Prow and coreos-ci Jenkins infrastructure
Remove the legacy CI artifacts that are no longer in use:
- ci/prow/: No-op placeholder Dockerfile and script that were kept
while waiting for the job to be removed from openshift/release.
Remove them entirely so Prow stops running on every PR.
- .cci.jenkinsfile: Orphaned coreos-ci Jenkins pipeline. Not
referenced by anything in the repo and superseded by GitHub
Actions and Konflux.
- ci/installdeps.sh: Remove stale comment referencing the Prow job.
The Prow job was already removed from openshift/release:
https://github.com/openshift/release/pull/81042
tests: Fix "remote:branch" test to use ostree_parse_refspec
ostree_validate_rev() validates bare ref names and does not accept
the "remote:ref" refspec syntax — the colon is not part of the
OSTREE_REF_REGEXP regex. The "remote:branch" form is a refspec,
which is parsed by ostree_parse_refspec().
Replace the incorrect ostree_validate_rev() call with
ostree_parse_refspec() and verify the parsed remote and ref
components, preserving the original test intent.
The file introduced in commit ac10a27d was not run through
clang-format before merging. Reformat the invalid_333 char array
initializer to comply with the project's .clang-format rules.
kargs: Fix crash on quoted values in /proc/cmdline
Bootloaders like GRUB may reformat quoted kernel arguments, producing
entries like "testparam=value with spaces" in /proc/cmdline. The
proc-cmdline parser was still using a naive space split (pre-dating the
quote-aware splitter added in abc7d5b9), so these tokens got broken
apart and hit a g_assert_false() abort downstream.
Use the quote-aware splitter for /proc/cmdline too, and downgrade the
unterminated-quote assert to g_debug() since we can't control what
bootloaders emit.
Reported by Arch Linux maintainers building ostree 2026.1.
Closes: https://github.com/ostreedev/ostree/issues/3582 Assisted-by: OpenCode (Claude Opus 4.6) Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
tests/kolainst: Fix failures on container-native FCOS
On container-native FCOS (F44+), /etc/ostree/remotes.d/ may have no
.conf files since the system uses container-based updates rather than
traditional ostree remotes. This caused test failures:
- staged-deploy.sh and finalization.sh: sed on the unexpanded glob
'/etc/ostree/remotes.d/*.conf' fails under set -euo pipefail when
no files match. Fix by iterating with a for loop and guarding with
test -f.
- itest-remotes.sh: 'ostree remote list' returns empty, hitting
assert_not_reached. Fix by skipping the test gracefully on systems
with no remotes configured.
Assisted-by: OpenCode (Claude Opus 4.6) Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
sysroot: Merge bootconfig-extra from previously staged deployment
When a staged deployment is replaced by a new one (e.g. bootc sets
source-tracked kargs, then rpm-ostree appends a karg before reboot),
the bootconfig-extra keys from the first staging were lost. The new
staging only checked the new deployment's bootconfig (always empty)
and fell back to the merge deployment's bootconfig (the booted BLS
file), which had no knowledge of what was in the previous staged
GVariant.
Fix this by merging bootconfig-extra from three sources in priority
order:
zipl: Switch from genprotimg to pvimg for SE boot image generation
el9, el10 and rhel-9.6 now ship s390utils-base >= 2.36.0, which
replaces the obsolete genprotimg tool with pvimg. Update the Secure
Execution boot image generation to use 'pvimg create' with long-form
flags (--kernel, --ramdisk, --parmfile, --output).
The pvimg tool natively supports the --overwrite option, eliminating
the need to manually remove the existing sdboot image before
regeneration.
ci/prow: Use RPMs with dnf instead of raw file overlay
The builder and coreos-assembler images may ship different library
versions (e.g. gpgme), causing soname mismatches at runtime. Use RPM
overrides for cosa and dnf for the container itself.
Eric Curtin [Mon, 8 Jun 2026 20:53:06 +0000 (21:53 +0100)]
static-delta: remove unused total_usize variable
In _ostree_delta_get_endianness, total_usize was accumulated across
delta parts but never read or used in any heuristic or output. Remove
the dead variable and its accumulation.
trivial-httpd: Fix const-correctness of slash pointer
strrchr() returns a 'const char *' when passed a 'const char *'
argument. Declare the local 'slash' variable as 'const char *'
to match, fixing a build failure with clang when
-Werror,-Wincompatible-pointer-types-discards-qualifiers is active.
wangzhaohui [Wed, 24 Jun 2026 01:00:47 +0000 (09:00 +0800)]
repo: Fix validation for min-free-space-percent config option
Add explicit validation that the string contains only digits before
converting to a number. This ensures invalid values are rejected with
a clear error message.
wangzhaohui [Tue, 23 Jun 2026 06:28:31 +0000 (14:28 +0800)]
pull: Fix GLib assertion crash on invalid UTF-8 ref names
When ostree pull or ostree pull-local receives a branch name containing
invalid UTF-8 bytes, g_variant_new_strv() triggers a GLib-CRITICAL
assertion failure on g_utf8_validate(), followed by a NULL pointer
dereference and segmentation fault.
Jonas Svatos [Thu, 11 Jun 2026 08:02:44 +0000 (10:02 +0200)]
checkout: Fix GVariant leak when scanning for opaque whiteouts
Breaking out of g_variant_iter_loop() leaves ownership of the current
element with the caller. The opaque-whiteout scan in
checkout_tree_at_recurse() breaks out of the loop when it finds a
match, and then cleared the local pointer, leaking one reference to
the extracted checksum variant on every directory that contains an
opaque whiteout entry.
A leaked child variant keeps the whole backing dirtree object alive,
including its GMappedFile when the object was large enough to be
mmap'd rather than read into the heap. In a process that unmounts the
target filesystem afterwards - notably `bootc install to-disk`, which
checks out container layers with process_whiteouts enabled and then
unmounts the physical root - the stale mapping makes the final
`umount -R` fail with EBUSY, aborting the installation.
Since the scan only needs the entry name, pass NULL to skip extracting
the checksum entirely, so nothing needs freeing on the early exit.
Fixes: https://github.com/bootc-dev/bootc/issues/2246 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Jonas Svatos <jonas.svatos@nfa.cz>
John Eckersberg [Tue, 27 Jan 2026 19:54:58 +0000 (14:54 -0500)]
README.md: Link to top-level Atomic Desktops page
Remove individual references; variants are likely to be continually
added and removed over time, and hopefully the top-level landing page
stays in the same place so this list doesn't need maintained here.
Closes: #3565 Signed-off-by: John Eckersberg <jeckersb@redhat.com>
generator: Fix soft-reboot for var, sysroot, and boot
A bare `systemctl soft-reboot` on ostree/bootc systems was broken in
several ways because the generator and prepare-root were not accounting
for the fact that soft-reboot does not re-run the initramfs.
The var.mount unit had DefaultDependencies=yes, which pulled in implicit
After= dependencies on device units. After soft-reboot, these device
units get stuck in 'tentative' state while udev restarts, causing
var.mount to stall indefinitely. Fix this by setting
DefaultDependencies=no with explicit ordering After=local-fs-pre.target
sysroot.mount.
For /sysroot, systemd auto-generates the mount unit from mountinfo with
Conflicts=umount.target, causing it to be unmounted during soft-reboot
shutdown. Generate a drop-in with DefaultDependencies=no to prevent this.
We use a drop-in because the generator does not know the What= device
parameter — systemd gets that from mountinfo.
For /boot on same-partition setups, move the bind-mount from
ostree-prepare-root into the generator as a full boot.mount unit with
DefaultDependencies=no. This handles normal boot, bare soft-reboot, and
staged deployment soft-reboot uniformly. The static (non-systemd) path
in ostree-prepare-root-static.c retains its own bind-mount since the
generator does not run there.
Validated with plain disk and RAID1 kola tests on FCOS 43.
Fixes: https://issues.redhat.com/browse/RHEL-154075 Assisted-by: OpenCode (Claude Opus 4.6) Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
Xiaofeng Wang [Thu, 2 Apr 2026 03:36:20 +0000 (11:36 +0800)]
ci: Make fuse and libfuse-dev conditional for Debian Testing
The libfuse-dev and fuse (FUSE 2) packages have been removed from
Debian Testing (forky/sid). Move them out of the unconditional package
list and only install them on older Debian/Ubuntu versions that still
provide FUSE 2. FUSE 3 support is already handled via the libfuse3-dev
argument logic.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
Xiaofeng Wang [Thu, 2 Apr 2026 02:40:04 +0000 (10:40 +0800)]
ci: Install ca-certificates in Debian Testing pre-checkout setup
The debian:testing-slim image no longer includes ca-certificates by
default, causing the GitHub Actions checkout step to fail with an SSL
CA cert error when fetching the repository over HTTPS.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
bootconfig: Preserve extension BLS keys across staged deployments
When a deployment is staged via ostree_sysroot_stage_tree_with_options(),
the deployment metadata is serialized to /run/ostree/staged-deployment
as a GVariant. During finalization at shutdown,
_ostree_sysroot_reload_staged() creates a fresh OstreeBootconfigParser
and only restores the "options" key from the serialized kargs. Any
additional BLS keys that were set on the bootconfig are silently dropped.
The parse/write/clone paths in OstreeBootconfigParser already handle
unknown keys generically (the "Write unknown fields" loop in
write_at()), so keys survive direct deployments and in-memory
operations. The gap is exclusively in the staged deployment roundtrip,
where a fresh bootconfig is rebuilt from just the kargs strv.
This matters for the upcoming bootc `loader-entries set-options-for-source`
feature, which stores kernel argument ownership as extension BLS keys
(e.g. `x-options-source-tuned nohz=full isolcpus=1-3`). On bootc
systems with transient /etc, tools like TuneD lose track of which kargs
they own because their state files are wiped on reboot. Tracking
ownership directly in the BLS config on /boot solves this, but only if
the keys survive staging. systemd-boot, GRUB, and zipl all ignore
unknown BLS keys, so extension keys are safe.
Fix this by following the same pattern used for overlay-initrds:
1. Add _ostree_bootconfig_parser_get_extra_keys_variant() which returns
all non-standard BLS keys as an a{ss} GVariant. Standard keys
(title, version, options, linux, initrd, devicetree) are excluded
since they are rebuilt from scratch during finalization. All other
keys are preserved, trusting the caller.
2. In ostree_sysroot_stage_tree_with_options(), serialize any extra
keys as "bootconfig-extra" in the staged GVariant dict. Since
_ostree_deployment_set_bootconfig_from_kargs() creates a fresh
bootconfig with only the "options" key, the code falls back to
the merge deployment's bootconfig for extra keys. This ensures
keys are inherited across staged deployments without the caller
needing to re-set them.
3. In _ostree_sysroot_reload_staged(), restore extra keys from the
"bootconfig-extra" dict onto the deployment's bootconfig via
ostree_bootconfig_parser_set().
The function is private (_ostree_ prefix) since only ostree's own
staging code uses it. No new public API, no changes to .sym files,
no changes to GIR or Rust bindings.
Backwards compatibility:
- Old ostree ignores the unknown "bootconfig-extra" key in the a{sv}
dict (extension keys silently lost, same as before this patch).
- New ostree gracefully handles the absence of "bootconfig-extra" in
staged data written by older versions (g_variant_dict_lookup returns
FALSE, no restoration attempted).
Assisted-by: OpenCode (Claude claude-opus-4-6) Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
Xiaofeng Wang [Tue, 31 Mar 2026 07:31:32 +0000 (15:31 +0800)]
ci: Use Justfile targets in GitHub workflow and add missing v2024_7 feature
- Replace inline cargo fmt/clippy commands in rust.yml with just
cargo-fmt-check and just cargo-clippy for consistency with local dev
- Make Justfile cargo-clippy use CARGO_PROJECT_FEATURES env var
(defaults to v2022_6) so CI and local use share the same config
- Add missing v2024_7 feature to Cargo.toml to fix cargo doc failure
caused by unexpected cfg condition
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
Xiaofeng Wang [Tue, 31 Mar 2026 07:15:30 +0000 (15:15 +0800)]
ci: Add Rust validate targets to Justfile for local development
Add just targets mirroring the CI Rust checks so developers can run
them locally before pushing:
- validate: runs both fmt and clippy checks
- cargo-fmt-check: checks formatting across all crates
- cargo-clippy: runs clippy with the same lint config as CI
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
projects / ostree.git / log